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(54) Method and system for a unicast endpoint client to access a multicast internet protocol (ip) 
session 



(57) Unicast endpoint clients (1 10, 1 1 1 , 1 1 5) on an 
IP Unicast network (107, 108) are provided access to 
Multicast sessions on an IP Multicast network (101) 
through a Multicast-Unicast gateway server (120, 121). 
The server obtains information about sessions on the 
Multicast network and makes such information available 
to a Unicast client on the Unicast network upon request 
by the client Upon being presented with a list describ- 
ing the subject matter of each session, the user at the 
Unicast client selects the session to which he or she 
wants to join, which causes the Multicast-Unicast server 
to join the appropriate session on behalf of the request- 
ing client for each media type in which the joining client 
wants to be a participant. The server then sets a bi- 
directional Unicast User Datagram Protocol (UDP) 

FIG. t 

110 



stream between itself and the client. All packets then 
received by the server from the Unicast client are 
address-translated to the appropriate Multicast session 
address. In addition, all packets received by the server 
on the Multicast session address are address-trans- 
lated and sent to the Unicast client The Unicast client is 
then able to participate in the Multicast session as both 
a sender ant? a receiver of packets to and from other 
Unicast and Multicast clients which are active during the 
session. Further, the Unicast client is capable of creat- 
ing a new session, recording a session in the network 
for later retrieval and playback, and creating and 
accessing low bandwidth versions of existing sessions. 




1 



EP0902 569A1 



2 



Description 
Tephn|c?| Ffclfl 

[0001] This invention relates to data communications, 
and more particularly, to providing a Unicast endpoint 
client on a Unicast network with the ability to access a 
Multicast session on an Multicast network. 

Background of the Invention 

[0002] In conventional packet, frame or cell based 
systems there are typically two modes of communica- 
tion: point-to-point (also known as Unicast) and point-to- 
muftipoint (also known as Multicast). Multicast 
addresses typically differ from Unicatst addresses in that 
they refer to an intermediate abstraction known as a 
group All senders address their transmitted information 
to this group and all receivers are "tuned" to "listen" to 
that address to receive the information transmitted to 
that group by the senders. The senders of information 
are thus effectively de-coupled from the set of receivers. 
Senders do not need to know who the receivers are - 
they simply transmit packets addressed to the group 
Similarly, receivers do not need to know who the send- 
ers are - they simply send a request to the network 
(routers) to join a specifte group of interest 
[0003] Multimedia distribution and conferencing/col- 
laboration systems are advantageously and efficiently 
supported by Multicast communication methods. As will 
be used herein, a specific Multicast communication is 
referred to as a session. In the prior art, it is not possible 
for Unicast endpoints to access Multicast sessions, due 
to the differences in addressing modes and receiving 
modes. This disadvantageous^ limits the ability of a 
user at a Unicast endpoint client to participate in ses- 
sions in which they have interest and in which they 
could be an active participant. 

Summary of the Invention 

[0004] In accordance with the present invention, Uni- 
cast endpoint clients are enabled to access Multicast 
sessions. Furthermore, in accordance with the present 
inventions, Unicast endpoint clients are enabled to 
request network-based recording systems perform 
recordings of the Multicast session on behalf of clients. 
Even furthermore, in addition to LAN attached end- 
points, analog dial-up (e.g., 28.8 kbps) as well as ISDN 
Unicast endpoints are enabled to access appropriately 
bandwidth-reduced versions of nominally high band- 
width sessions. 

[0005] Inter-connectivity between a Unicast client con- 
nected to a Unicast network and one or more Multicast 
clients connected to a Multicast network is effected 
through a Multicast-Unicast Server (MUS), in accord- 
ance with the present invention. Such a server obtains 
information about sessions on the Multicast network 



and makes such information available 1o the Unicast ci- 
ent on the Unicast network upon request by the cfierit 
Upon being presented with a list descrtoing the subject 
matter of each session, the user at the Unicast client 

5 selects the session to which he or she wants to join, 
which causes the Multicast-Unicast server to join the 
appropriate session on behalf of the requesting client 
for each media type for which the joining client wants to 
be a participant. The server then sets a bi-directional 

w Unicast User Datagram Protocol (UDP) stream 
between itself and the client. All packets then received 
by the server from the Unicast client are address-trans- 
lated to the appropriate Multicast session address. In 
addition, aO packets received by the server on the MuHi- 

75 cast session address are address-translated and sent 
to the Unicast client The Unicast client is then able to 
participate in the Multicast session as both a sender 
and a receiver of packets to and from other Unicast and 
Multicast clients which are active during the session. 

20 Further, such a Unicast client, if authenticated to do so, 
is capable of creating a new session, and of recording a 
session in the network for later retrieval and playback. 
Furthermore, transcoding and rate adapting gateways 
are deployed within the Multicast network that map 

25 existing sessions into low bandwidth versions. If the 
Unicast client is a dial-up user connected to the Unicast 
network over analog or ISDN facilities, these rate-con- 
trolled sessions can then be accessed by the dial-up 
users. 

30 

Brief Description of the Drawings 
[0006] 

6 FIG. 1 is a block diagram showing Unicast clients 
connected on a Unicast Internet Protocol (IP) net- 
work accessing an IP Multicast network through 
Multicast-Unicast Servers (MUS's); 

FIG 2 is a block diagram of a MUS; 
40 FIG. 3 shows the software components of a client 
terminal that enable the client to access a Multicast 
session; 

FIG. 4 is a flowchart detailing the steps associated 
with a Unicast client joining a Multicast session on 

45 the Multicast network; 

FIG. 5 is a flowchart detailing the steps of a Unicast 
client creating a Multicast session; 
FIG. 6 is a flowchart detailing the steps of a Unicast 
client recording a Multicast session; and 

so FIGS. 7A and 7B together detail the steps of a Uni- 
cast client rate-adapting/transcoding a Multicast 
session. 

Detailed Description 

55 

[0007] With reference to FIG. 1 , an IP Multicast net- 
work 1 01 is shown including, as way of illustration, three 
interconnected Multicast Routers (MR) 102-1, 102-2, 
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and 102-3. A well known currently in place IP Multicast 
network is the so-called MBONE (Multicast Backbone), 
which is a public shared IP Multicast network spanning 
many countries and covering thousands of IP sub-net- 
works. In addition to the MBONE, numerous private 
Intranets also use Multicast IP for intra-corporate com- 
munications. A plurality of multimedia client terminals 
are connected to IP Multicast network 101, for example 
the MBONE. For way of illustration only, In FIG. 1 two 
client terminals 103 and 104 are shown connected to 
network 101 through respective Local Area Networks 
(LANs) 105 and 106, respectively. Each LAN is con- 
nected through a customer premises router (not shown) 
over, for example, a T1 line. Frame Relay (FR), ATM, or 
an X.25 connection. In accordance with Multicast com- 
munication, a sender of information of a particular 
media type transmits packets of information to a partic- 
ular address, which are then automatically distributed to 
each of the members of a group that have requested to 
receive from that address. Advantageously, the network 
performs the replication, functions necessary so that 
each receiver client of the group can receive the pack- 
ets transmitted to the address by a sender or senders. 
[0008] In accordance with the present invention, Uni- 
cast client terminals connected to a Unicast IP network 
is capable of joining in and participating with a Multicast 
session on an IP Multicast network. FIG. 1 shows two 
Unicast IP networks 107 and 108. Illustrative Unicast 
client terminals 110. and 111 are connected to network 

107 through conventional Unicast Routers (URs) 112 
and 1 1 3, respectively. Unicast client terminal 1 1 5 is con- 
nected to UR 1 16 within network 108. UR 1 16 in turn is 
shown connected to another UR t UR 117 for example, 
which in turn is connected to UR 1 18. Networks 107 and 

108 are shown as being interconnected through UR 1 12 
and 118, thus enabling Unicast IP communication 
between a client terminal connected to Unicast IP net- 
work 107and a client terminal connected to Unicast IP 
network 108. The Unicast client terminals 1 10, 1 1 1 and 
115, for example, can be connected to networks 107 or 
108 gver a Plain Old Telephone Service (POTS) dial-up 
connection, an ISDN connection or an Asynchronous 
Digital Subscriber Loop (ADSL) connection, each to a 
Local Exchange Carrier (LEC) (not shown) and from 
there to an Internet Service Provider (ISP) (not shown), 
which in turn is connected to the Unicast IP network 
through a Unicast Router. Alternatively, a client terminal 
can be connected to an ISP through a cable modem 
over cable facilities through a cable TV provider. Even 
further, the Unicast client terminal could be connected 
to a LAN and to a customer premises router to a UR 
over, for example, a Wide Area Network (WAN), T1 facil- 
ities, Frame Relay, ATM, or X.25. In accordance with 
this invention, Unicast client terminals 110. 1 1 1 , 1 1 5, for 
example, on Unicast IP networks 107 and 108, can par* 
ticipate in a Multicast IP session on IP Multicast network 
101. Specifically, such functionality is enabled through 
Multicast-Unicast Servers (MUS's), such as MUS 120 in 



network 107 and MUS 121 in network 108, which each 
interconnect their respective Unicast IP networks 107 
and 108, with the IP Multicast Network 101. 
[0009] The Multicast-Unicast Servers 120 and 121 

5 function as gateways that enable those Urticast-con- 
nected clients on their respective Unicast IP networks to 
access IP Multicast network 101. Specifically, each 
MUS through interaction with client software on the Uni- 
cast client on the Unicast IP network enables such client 

to to join a group on the IP Multicast network by providing 
information relating to what sessions are in progress or 
scheduled on network 1 01 . JTie MUS then receives and 
sends data on those groups within a session selected 
by client on behalf of the client Thus, the MUS functions 

is to convert the address of the Multicast IP packets of a 
requested-for group to the Unicast IP endpoint address 
of the requesting client. Furthermore, the MUS func- 
tions to transmit packets it receives from the Unicast 
endpoint client to a list of any other Unicast endpoint 

so receivers for the requested-for Multicast group on the 
same Unicast IP network or an interconnected Unicast 
IP network (107 or 108), as well as to the Multicast 
group address itself on the IP Multicast network 101 to 
enable the Multicast endpoints, 103 and 104, for exam- 

25 pie, connected on that network to receive packets origi- 
nating from the Unicast client 
[0010] FIGS. 2 and 3 are block diagrams of an MUS 
201 and a client terminal 301, respectively, showing 
their functions that enable them to operate in accord- 

30 ance with the present invention, in FIG; 2 a Session 
Description Protocol (SDP) listener process 202 cou- 
pled to the IP Multicast network 101 listens for session 
announcements transmitted on Multicast network 101. 
Such directory announcements are repeatedly sent 

35 over the IP Multicast network 101. These "advertised" 
sessions are received by the SDP/SAP advertised proc- 
ess 203 and stored in a sessions database 204. Other 
sessions that are not announced and thus not received 
by the SDP listener process 202, are entered by a sys- 

40 tern administrator through a static sessions process 205 
and also stored in sessions database 204. An example 
of the latter might be a weather channel that is always 
present on a predetermined socket and is not repeat- 
edly announced over the IP Multicast network 101 . 

45 [0011] An HTTP server 206 can read the sessions 
database 204 so that when a client connects to the 
server, the client is able to receive a listing of those Mul- 
ticast sessions presently on the IP Multicast network 
101. When the client connects to the server 206, the 

so server executes a CGI (Common Gateway Interlace) 
scripts 207 within the HTTP server 206 on behalf of the 
client to present the information pertaining to the ses- 
sions to the client. Such information is presented back 
. to the client 301 (FIG. 3) through its web browser pro- 

55 gram 302 (in FIG. 3). The client initiates a request to join 
a session by selecting a URL on an HTML web page 
presented to it by HTTP server 206. A message is thus 
sent from the client 301 by web browser 302, which 
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when received by server HTTP 206 causes it to invoke 
certain actions. Specifically, HTTP sewer 206 sends a 
response back to the client comprising a control mes- 
sage containing information indicating what tool needs 
to be used in order to join the selected session. Such 5 
tools are well known in the art and may include, for 
example, the Visual Audio Tool (VAT), the Visual Confer- 
ence Tool (VIC), or the Internet Protocol Television Tool 
(IPTV). Furthermore, the message indicates where the 
tools should be connected, i.e., specifically, to which 10 
socket on the MUS the tool should be connected. On 
the client side, the client 301 then launches from launch 
program 303 the specified tool from tool program 304 to 
the indicated sockets on the MUS 201 . CGI scripts pro- 
gram 207 then initiates the translation/packet-forward- 16 
ing server 208 within MUS 201 to join the requested 
Multicast group or groups (one group per selected 
media type) associated with the selected session. CGI 
scripts 207 that initiated such join action to take place 
then adds that client's Unicast address to a list of receiv- go 
ers for the requested Multicast group or groups. Server 
208 then forwards Multicast packets received from the 
dient to the list of receivers for each joined group and 
translates the Multicast address of packets received 
from the joined group to the Unicast address of the join- 
ing client. 

[001 2] The steps associated with a client joining a 
session are detailed with reference to the flowchart in 
FIG. 4. At step 401, the SDP listener process accumu- 
lates IP Multicast network 101 directory announce- 
ments into database 204. The database is filtered and 
converted into a standard HTML page, where each URL 
points to information pertaining to each Multicast ses- 
sion in the filtered database. At step 402, the HTTP 
server 206 listens for requests for Multicast ses- 35 
sions/URLs on the HTML page which contains a list of 
URLs describing the sessions. At step 403, a request is 
received fronri a client for a copy of the page containing 
the Multicast sessions. At step 404, the HTTP server 
206 sends a message back to the client requesting the 40 
user enter a login id and a password for authentication 
purposes. If the user is successfully authenticated at 
step 405, at step 406, server 206 returns a page to the 
client containing a list of sessions. When, at step 407, 
the user of the client browses the page and requests a 45 
session indicated by a URL, at step 408, server 206 
returns a page containing detals of the session and but- 
tons enabling the client to request the session to start, 
as well as other functions to be described later herein. 
At step 409, the client starts a selected session (or spe- so 
cif ic media in the session) by jessing" a button on the 
HTML page. The server 206 then launches a control 
script 207. At step 410, the control script 207 sends a 
response to the client containing information about 
which multimedia tool to launch, and what UDP sockets ss 
(the Unicast IP address on the MUS and associated 
ports) to listen to and to send information to correspond- 
ing to the requested group. It can be assumed that at 



least one socket is used. A second socket may be used 
to send control/status information from each member of 
the Multicast group. At step 41 1 , the same control script 
207 of server 206 causes the Multicast-to Unicast gate- 
way to pin the requested-for Multicast group and adds 
the requesting client to the list of receivers tor the 
requested for Multicast group. For each requesting cli- 
ent, server 206 also converts the address of the Multi- 
cast IP packets of the requested-for group to the 
Unicast IP address of the requesting client, and sends 
the Unicast IP packets to the requesting client using the 
well-known User Datagram Protocol (UDP). Server 206 
also transmits any packets it receives from the client to 
any other Unicast client on that Multicast group, as well 
as to the Multicast group address itself on the IP Multi- 
cast network 101. At step 412, when the client exits 
from the multimedia tod, server 206 detects that status 
messages from the client are no longer being sent and 
removes the client from the list of destinations for the 
particular Multicast group. 

[001 3] The steps associated with a client creating a 
hew session are detailed in FIG. 5. At step 501, as pre- 
viously described in connection with the steps in FIGL 4 
associated with a client joining a session, the SDP lis- 
25 tener process 202 accumulates IP Multicast network 
101 directory announcements into database 204. The 
database is filtered and converted into a standard 
HTML page, where each URL points to information per- 
taining to each Multicast session in the Jittered data- 
30 basa At step 502, the HTTP server 206 listens for 
requests for Multicast sessions/URLs on the HTML 
page which contains a list of URLs describing the ses- 
sions. When a user of a client requests a copy of the 
page containing the Multicast sessions at step 503, the 
server 206, at step 504, sends a message back to the 
client requesting a login id and password for authentica- 
tion purposes. If authentication is successful at step 
505, at step 506, server 206 returns a page to the client 
containing a list of sessions. When the user browses 
that page and requests a specific URL,, server 206, at 
step 507, returns a page containing details of the ses- 
sion and buttons enabling the client to request a session 
to start, to create a new session, to edit or delete an 
existing session, and to record the current session, the 
later functionality to be descrfoed hereinafter. When, at 
step 508, the user "presses" a button to create a new 
session, at step 509, server 206 returns a form to the 
client requesting the client to enter a login id and pass- 
word appropriate for creating a new session, which may 
or may not be the same as the login id and password 
associated with the initial authentication process. If. at 
step 510, the client is authenticated for session crea- 
tion, server 206 returns at step 51 1 a form to the client 
with fields to be filled in by the user for the session 
name, session description, a URL address for more 
detailed or related information, a field to set the Multi- 
cast packet Time to Live value (TTL), selection boxes for 
various media tools, and associated coding formats, 
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Multicast addresses and ports to use, the name and "push" when the form is complete. When the user f ills in 
phone number of a responsWe person, and the dura- the fields and selects the start form, the filled-in form is 
tion of the session announcement. When the user fills in returned to server 206. Server 206 checks that certain 
the fields and selects a create button, the fBled-in form key fields are correct and filled in. If not, an error mes- 
is returned to the server 206. Server 206 checks that s sage is returned to the client; otherwise the server 
certain key fields are correct and filled in. If not, an error stores the data in a file that is indexed to the login id 
message is returned to the client; otherwise server 206 used to access the form. At step 6,1 1 , server 206 sends 
stores the data in a file that is indexed to the login id a message to the recording server 125 to start the 
used to access the form. The data, at step 512, is then recording at the specified date and time. The recording 
made available to a Session Announcement Protocol 10 server 125, at step 612, then records the session at the 
(SAP) process 210 on MUS 201. At step 513, the SAP appropriate time using a well-known program for read- 
process 21 0 periodically announces the session onto a ing IP Multicast packets in the FTP formal At step 61 3, 
well-known Multicast IP address and port reserved for the stored session is retrieved on-demand by the user, 
such announcements for a period of time equal to the [0015] To support dial-up Unicast endpoint users, 
duration field as entered in the form. When this time is prior art transcocfing and rate adapting gateways, such 
period expires, the SAP process 210 ceases to as transcoder/adapter 127 in FIG. 1, are deployed 
announce the session. within IP Multicast network 101. As shown in FIG. 1, 
[0014] A Unicast endpoint can also, in accordance transcoder/rate adapter gateway 127 is connected via 
with the present invention, request that a session be LAN 128 to the IP Multicast network 10t. Alternatively, 
recorded for later rebroadcast or retrieval oh demand, so transcoder/rate adapter gateway 127 may be co-resi- 
To effect such recording, m FIGi 1. a recorder 125 is dent with either MUS 120 or 121. The gatiaway maps 
connected via LAN 126 to the IP Multicast network 101. existing high bamdwidth sessions into low bandwidth 
The flowchart in FIG. 6 details the steps associated with versions of the same session suitable for 28.8 kbps 
a user at a client terminal requesting that a session be modems or ISDN adapters by usih^ frame discarding 
recorded. As described previously, the client must be 25 algorithms. Announcements aboirtittiese rate-controlled 
given a login kJ and password to enable access to the sessions are then placed in the database 6f IP Multicast 
HTTP server 206 which has a list of the IP Multicast network 101 sessions. ' • 
sessions. At step 601. the SDP listener process 202 [0016] An alternative mechanism for ir^okirig the 
accumulates IP Multicast network 101 directory transcoding/rate adapt^ 

announcements into sessions database 204. The data- 30 user/client action. The Steps associated with* a cfifent 
base is filtered and converted into a standard HTML requesting that a session be automatically trans- 
page, where each URL points to information pertaining coded/rate adapted are detailed in FIGS. 7A and 7B. As 
to each Multicast session in the filtered database. At described previously, the user of the client must be 
step 602, server 206 listens tor requests for Multicast given a login id and a password to enable access to 
sessions/URLs on the HTML page which contains a list 35 HTTP server 206. As described previously, at step 701 , 
of URLs describing the sessions. When, at step 603, a the SDP listener process 202 accumulates IP Multicast 
user requests a copy of the page containing the Mutti- network 101 directory announcements into database 
cast sessions, at step 604, server 206 sends a message 204. The database is filtered and converted into a 
backto the client requesting his or her login id and pass- standard HTML page, where each URL points to inforr 
word for authentication purposes. If, at step 605, 40 mation pertaining to each Multicast session the fBtered 
authentication is successful, at step 606. server 206 database. It is assumed that a required bandwidth 
returns a page to the client containing a list of sessions. parameter and maximum packet loss parameter are 
When a user browses that page and requests a URL, associated with each session. For sessions using a 
server 206, at step 607, returns a page containing form as previously described, this is accomplished by 
details of the session, and buttons enabling the client to 45 the use of additional fields corresponding to these 
request a session, to start the existing session, to ere- parameters in the "new session" form described herein- 
ate a new session, to edit or delete an existing session, above. At step 702, HTTP server 206 listens for 
or to record the current session. At step 608, the user . requests for Multicast sessions/URLs on the HTML 
"presses" a button to record a session and, at step 609, page containing a list of URLS describing the sessions, 
server 206 returns a form to the client requesting the so When, at step 703, a request is received from a client for 
user to enter a login id and password for recording pur- a copy of the page containing the Multicast sessions, at 
poses, which may or may not be the same as the iogin step 704, server 206 sends a message back to the di- 
id and password used in a previous step. If, at step 610, ent requesting a login id and password for auth^ntica- 
the client is authenticated for session recording, server tion purposes. If, at step 705. authentication is 
206 returns a form to the client with fields to be filled in ss successful, at step 706, server 206 returns a page to 
or options to be selected. The form contains selection the client containing a list of sessions. When after the 
boxes for the various media of the session, and start user browses the page, and at step 707, selects a ses- 
and stop date and time fields, as wen as a start button to sion and group(s) within a session, server 206, at step 
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708, returns a page containing details of the session 
and buttons enabling the client to request a session to 
start, to create a new session, to edit or delete an exist- 
ing session, or to record the current session. At step 

709, the user pushes a button to request the session or 5 
specific mecfia in the session to start In response 
thereto, at step 710, server 206 launches a control 
script which sends a series of test packets to the client 

At step 71 1 , the client echoes these same packets back 
to the server 206. At step 712, the server computes an 10 
estimate of the available bandwidth and packet loss 
along the path between the server and the client by 
comparing the transmitted test packets with the 
received test packets. H, at decision step 713, the per- 
formance requirements of the session exceed that of is 
the path, at step 714, rate-adaptation or transcoding is 
heeded. If not, the process continues as previously 
described for a client joining an existing session. If rate 
adaptation or transcocfing is needed, at step 715, one 
out of plurality of lower rate encocfings is selectedbased so 
on the measured characteristics of the path, rt is to be 
assumed that a finite set of rate adapted sessions are 
allowed by the server 206. As an example, if the original 
session was 128 kbps. rate adaptation to 56 tops, 28.8 
kbps and 20 kbps may be allowed. At step 716, HTTP & 
server 206 sends a message to the transcoding/rate 
adapting gateway 127 indicating which Multicast group 
is to be joined, to what bandwidth the media-type should 
be rate-adapted, what (if any) alternative coding needs 
to applied, and what new Multicast address and port 30 
number the transcoded session should use. At step 

717, a determination is made whether that group has 
already been rate-adaptedrtranscoded. If yes, at step 

718, the Multicast address and port number corre- 
sponding to the already rate-adapted/transcoded group 35 
is used and the process proceeds to step 719. If no, at 
step 720, the transcoder/rate adapter gateway 127 is 
invoked to transcode the session with appropriate band- 
width parameters and to re-Multicast the resulting 
lower-bandwidth session using a different Multicast 40 
address and port number. At step 719, the server 206 
sends a message to the client containing information 
about which multimedia tool to launch, and what UDP 
sockets (the Unicast IP address on the MUS and asso- 
ciated ports) to listen to and to send information to cor- 45 
responding to the requested session. At step 721, the 
control-script causes the MUS gateway to join the 
requested Multicast group and add the requesting client 

to the list of receivers for requested Multicast group. For 
each requesting client the server converts the address so 
of the Multicast IP packets of the requested-for group to 
the Unicast IP address of the requesting client, and 
sends the Unicast IP packets to the requesting client 
using the well-known User Datagram Protocol. The 
server also transmits any packets it receives from the 55 
client to the list of receivers for that Multicast group, as 
well as to the Multicast group address itself. At step 722, 
when the client exits the multimedia tool, the HTTP 



server 206 detects that status messages from the client 
are no longer being sent and removes the client from 
the list of destinations for the particular Multicast group. 
[0017] The system described hereinabove is highly 
scaleable in that the MUS and other servers may be dis- 
tributed throughout the Multicast-enabled portion of the 
network If the number of such endpoints is Gkefy to be 
large, for efficiency, it is preferred that the servers be 
located close to the Unicast client endpoints. For small 
conferencing group, the location or distribution of the 
MUS's is not important Advantageously, the present 
invention enables any IP Multicast-based service to be 
gradually introduced and rolled put on a small scale 
before all clients are enabled for IP Multicast. As clients 
become IP Multicast enabled, there could be a transi- 
tion to a hybrid IP Multicast mode of operation where 
some clients are IP Multicast connected and others are 
not 

[0018] Although described in connection with Unicast 
IP endpoints connecting to an IP Multicast network 101 
such as the MBONE, the present invention could be 
employed with any IP Multicast network Further the 
present invention could be employed with any Multicast 
network and Unicast network that operate in a similar 
fashion to IP Multicast and Unicast networks. 
[0019] The above-descrtoed embodiments are illus- 
trative of the principles of the present invention. Other 
embodiments could be devised by those skilled in the 
art without departing from the spirit and scope of the 
present invention. 

[0020] Where technical features mentioned in any 
claim are followed by reference signs, those reference 
signs have been included for the sole purpose of 
increasing the intelligibility of the claims and accordingly 
such reference signs do not have any limiting effect on 
the scope of each element identified by way of example * 
by such reference signs. 

Claims 

1 . A method of providing access to a Multicast session 
on a Multicast network to a Unicast client on a Uni- 
cast network comprising: 

accumulating at a gateway server interconnect- 
ing the Multicast network and the Unicast net- 
work directory information relating to Multicast 
sessions on the Multicast network; 
supplying the Unicast client with the directory 
information accumulated by the gateway 
server; 

receiving at the gateway server from the Uni- 
cast client a request to join a selected session 
chosen from the directory information; 
joining the requested-for Multicast session at 
the gateway server on behalf of the Unicast cfi- 
ent; 

converting at the gateway server an address of 
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Multicast packets received on a Multicast 
address associated with the requested-for ses- 
sion to a Unicast address off the Unicast client 
and sending the Multicast packets received by 
the gateway server on the Multicast address to s 
the Unicast client; and 

transmitting packets received at the gateway 
server from the Unicast client to the Multicast 
address associated with the requested-for ses- 
sion, w 

2. The method off claim 1 wherein the request to join a 
Multicast session is a request to join at least one 
group of a plurality off groups associated with the 
Multicast session, each of said plurality of groups is 
having an associated Multicast address. 

3. The method of claim 2 wherein each of said at least 
one group is associated with a different media type. 

! 20 

4. The method of claim 1 further comprising before 
supplying the Unicast client with the directory infor- 
mation, authenticating the Unicast client 

5. The method of claim 4 wherein the authenticating 25 
comprises receiving at the gateway server a login 
identity and a password from the Unicast client < 

6. The method of daim 1 wherein the Unicast and j 
Multicast networks are IP internet Protocol) Uni- 30 
cast and IP Multicast networks, respectively. 

7. The method off claim 6 wherein packets are trans- 
mitted between the gateway server and the Unicast 
client using the User Datagram Protocol. 35 

8. The method of claim 6 wherein the directory infor- 
mation comprises an HTML page having a plurality 
of URLs each pointing to information associated 
with a Multicast session on the IP Multicast net- 40 
work 

9. The method of claim 6 wherein the IP Multicast net- 
work is the MBONE. 

45 

10. A method of creating a Multicast session on a Mul- 
ticast network by a Unicast client on a Unicast net- 
work comprising: 

accumulating at a gateway server interconnect- so 
ing the Multicast network and the Unicast net- 
work directory information relating to Multicast 
sessions on the Multicast network; 
supplying the Unicast client with the directory 
information accumulated by the gateway ss 
server; 

receiving a request at the gateway server from 
the Unicast client to create a Multicast session; 



receiving and storing at the gateway server 
information about the Multicast session; and 
announcing the Multicast session by the gate- 
way server onto the Multicast network onto a 
predetermined Multicast address for such 
announcements. 

11. The method of claim 10 wherein the Unicast and 
Multicast networks are IP (Internet Protocol) Uni- 
cast and IP Multicast networks, respectively. 

12. The method of claim 10 wherein the session is 
announced periodically onto the Multicast network. 

» 

13. The method of 10 further comprising before supply- 
ing the Unicast client with the directory information, 
authenticating the Unicast client 

14. The method of claim 13 further comprising after 
receiving a request at the gateway server from the 
Unicast client to create a session, authenticating 
the Unicast client to create a session. 

15. A method of recording a Multicast session on a Mul- 
ticast network by a Unicast client on a Unicast net- 
work comprising: 

accumulating at a gateway server interconnect- 
ing the Multicast network and the Unicast net- 
work directory information relating to Multicast 
sessions on the Multicast network; 
supplying the Unicast client with the directory 
information accumulated by the gateway 
server; 

receiving a request at the gateway server from 
the Unicast client to record a selected Multicast 
sessioachosen from the directory information; 
and 

sending a message containing information 
about the selected Multicast session from the 
gateway server to a recording server con- 
nected to the Multicast network to record the 
selected session. 

16. The method of claim 15 wherein the Unicast net- 
work and the Multicast network are IP (Internet Pro- 
tocol) Unicast and IP Multicast networks, 
respectively. 

17. The method of claim 15 further comprising receiv- 
ing at the gateway server from the Unicast client 
information about the selected Multicast session 
including when to start and stop recording. 

18. The method of claim 17 wherein the information 
received at the gateway server from the Unicast cli- 
ent further includes an identification of specific 
media to record of the selected Multicast session. 
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19. The method of claim 15 further comprising before 
supplying the Unicast client with the directory infor- 
mation, authenticating the Unicast client. 

• >- 

2a The method of claim 19 further comprising after 
receiving a request at the gateway server from the 
Unicast client to record a session, authenticating 
the Unicast client to record a session. 

21. The method of claim 15 further comprising: 
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receiving a request at the gateway server from 
the Unicast client to access the recorded ses- 
sion; 

sending a message to the recorcfing server 75 
from the gateway server to the recording server 
to retrieve the recorded session; 
receiving the recorded session at the gateway 
server; and 

sending the recorded session from the gateway so 
server to the Unicast client 

22. A method of providing access to a Multicast session 
on a Multicast network to a Unicast client on a Uni- 
cast network comprising 25 

accumulating at a gateway server interconnect- 
ing the Multicast network and the Unicast net- ' 
work directory information relating to Multicast 
sessions on the Multicast: network, the direc- 30 
tory information including for each session a 
Multicast address for the session and a 
required bandwidth of the session; 
supplying the Unicast client with the directory 
information accumulated by the gateway 35 
server; 

receiving at the gateway server from the Uni- 
cast client a request to join a selected session 
chosen from the directory information; 
determining an estimate of the available band- 40 
width between the gateway server and the Uni- 
cast client; 

if the estimate of the available bandwidth is less 
than the required bandwidth for the selected 
session, selecting a coding rate lower than a 45 
coding rate associated with the selected ses- 
sion; 

sending a message from the gateway server to 
a transcoding server connected to the Multicast 
network to rate-adapt the coding rate associ- so 
ated with the selected session to the selected 
lower coding rate; 

receiving at the gateway server from the trans- 
coding server an indication of the Multicast 
address to which the rate-adapted selected 55 
session is being transmitted; 
joining the rate-adapted session on behalf of 
the Unicast client at the gateway server on the 



indicated Multicast address to which the rate- 
adapted selected session is being transmitted; 
converting at the gateway server the address of 
the Multicast packets received on the Multicast 
address to which the rate-adapted selected 
session is being transmitted to a Unicast 
address of the Unicast client and sending the 
Multicast packets received by the gateway 
server on that Multicast address to the Unicast 
client and 

transmitting packets received at the gateway 
server from the Unicast client to the Multicast 
address to which the rate-adapted selected 
session is transmitted. 

23. The method of claim 22 wherein the Unicast and 
Multicast networks are IP (Internet Protocol) Uni- 
cast networks and IP Multicast networks, respec- 
tively. 

24. The method of claim 22 wherein the request to join 
a Multicast session is a request to join at least one 
group off a plurality of groups associated with the 
Multicast session, each of said plurality of groups 
having an associated Multicast address. 

25. The method of claim 24 wherein each of said plural- 
ity of groups is associated with a different media 
type. 

26. The method of claim 22 wherein determining an 
estimate of the available bandwidth comprises: 

transmitting a series of test packets to the Uni- 
cast client; 

receiving an echo of these test-packets back 

from the Unicast client; 

and 

comparing the transmitted series of test-pack- 
ets with the received echo of these test pack- 
ets. 

27. A Mufticast-Unicast server comprising: 

means for accumulating from a connected-to 
Multicast network directory information relating 
to Multicast sessions on the Multicast network; 
means for receiving from a Unicast client on a 
Unicast network connected to the server a 
request to join a Multicast session from among 
the sessions accumulated in the directory infor- 
mation; 

means for joining the requested-fbr Multicast 
session on behalf of the client; and 
means for converting the Multicast address of 
the Multicast packets on the requested-for Mul- 
ticast session to a Unicast address associated 
with the Unicast client and for sending the Mul- 
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ticast packets on the requested-for Multicast 
session to the Unicast client at that Unicast 
address, and for sending packets received from 
the Unicast client to the Multicast address 
associated with the selected session. s 

28. The server of claim 27 wherein the Multicast net- 
work and the Unicast network the server is con- 
nected to are an IP (Internet Protocol) Multicast 
network and an IP Unicast network, respectively. to 

29. The server of claim 28 wherein packets are trans- 
mitted between the server and the. Unicast client 
using the User Datagram Protocol. 

30. The server of claim 27 wherein the request to join a 
Multicast session is a request to join at least one 
group of a plurality of groups associated with the 
Multicast session, each of plurafity of groi*>s having 

an associated Multicast address. 20 

31 * The server of claim 30 wherein each of said plural- 
ity of groups is associated with a different media 
type. 

25 

32. The server of claim 27 wherein the means for con- 
verting also sencte packets received frbnv the Uni- 
cast client to another Unicast client associated with 
the server and which said another client is also con- 
nected to the session. 3 ° 
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